In telecommunications networks there exist many applications and services in order to provide extra functionality in addition to regular phone calls. These applications and services typically run on separate servers that are connected to the telecommunications network. These servers typically run on different platforms than the telecommunications network itself.
One such platform is the Java Enterprise Edition (JEE) platform, which is a development of the standard Java platform. JEE is a widely used platform for server programming in the Java programming language. The JEE Platform differs from the standard Java Platform in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server. A feature of the JEE platform is that it allows multiple processing threads to run in parallel, thereby increasing the throughput of task execution.
Although the JEE platform is suited for many applications, it can be impractical for certain telecommunication services, as described below.
The handling of telecommunication protocols typically requires the use of state machines associated with application sessions. For these state machines it is necessary to only receive one message at a time, so that the state is not corrupted. The JEE platform as such does not provide means for handling messages on a particular application session one at a time. On the contrary, the JEE platform will typically start as many parallel threads as there are messages to be processed.
FIG. 1 shows a typical JEE cluster 1 comprising multiple processors 3. The processors 3 may be identical and share the load of the JEE cluster 1. When used as a telecommunications processing platform each processor 3 will typically comprise several containers, for example Enterprise Java Beans 5 (EJB), HTTP servlet 7, a Session Initiation Protocol (SIP) Servlet 9 or other execution units 13, such as other resource adapters for communicating with legacy systems.
The architecture shown in FIG. 1 comprises a thread pool 19. The thread pool 19 comprises one or more processing threads t1 to tN for enabling the processor 3 to perform multiple tasks in parallel. The thread pool 19 also comprises a task queue 21 containing a set of tasks to be executed by the threads t1 to tN. Each processing thread t1 to tN handles one task at a time.
As mentioned above, a JEE platform is configured to try and execute as many tasks in parallel as there are threads defined in the system. This can be problematic when a JEE platform as described in FIG. 1 is being used to handle telecommunication applications and services, whereby a session state can become invalid when multiple threads t1 to tN execute multiple events associated with application sessions in parallel. In other words, the events in an application session are concurrently updating the same session state.
One method of ensuring event synchronisation is to use locks or semaphores to prevent events in an application session from concurrently updating the same session state. As such, when one thread t1 to tN is processing an event associated with a particular application session, all other threads must wait until the one thread is finished. This has the disadvantage of causing many threads t1 to tN to be waiting, which is not an optimal use of system resources, and generally in conflict with the JEE platform principles.
Another method of ensuring event synchronisation is to assign just one thread of the plurality of threads t1 to tN to each application session. As such, each application session has a dedicated thread for handling its events. However, such a solution has the disadvantage of foregoing the thread pooling mechanism, and therefore violates an important JEE platform principle that governs that all resources (including threads) must be managed. This solution also has the disadvantage of using much more threads t1 to tN than necessary, and is therefore not resource efficient.
It will be appreciated from the above that implementing event synchronization is problematic without compromising resource efficiency.